1. Technical Field
The present invention is directed to an improved data processing system and, in particular, an improved mechanism for permission based access control. More specifically, the present invention provides a mechanism through which a security provider may specify their own permission type and a permission type that can handle any application permission types.
2. Description of Related Art
In Java Development Kit (JDK) version 1.1, local applications and correctly digitally signed applets were generally trusted to have full access to vital system resources, such as the file system. Unsigned applets were not trusted and could access only limited resources. A security manager was responsible for determining which resource accesses were allowed.
In the Java 2 Software Developer's Kit (SDK), the security architecture is policy-based and allows for fine-grained access control. In Java 2 SDK, when code is loaded by the classloader, it is assigned to a protection domain that contains a collection of “permissions”) based on the security policy currently in effect. Each permission specifies a permitted access to a particular resource, such as “read” and “write” access to a specified file or directory, or “connect” access to a given host and port. The policy, specifying which permissions are available for code from various signers and/or locations, can be initialized from an external configurable policy file. Unless a permission is explicitly granted to code, it cannot access the resource that is protected by that permission. These concepts of permission and policy enable the Java 2 SDK to offer fine-grain, highly configurable, flexible, and extensible access control. Such access control can be specified not only for applets, but also for all Java code including but not limited to applications, Java beans, and servlets.
Because the Java 2 SDK provides such a flexible and extensible access control, Application vendors end up specifying different security policies in terms of their own permission types, thereby introducing their own type of permissions into the security policy. In order to provide access control functionality to these “customized” permissions, security provider implementors that create these custom permissions must make sure they understand these customized permission types and need to make sure they support them. For example, if the application code checks for “com.foo.security.AppPerm1”, then the security provider needs to check “com.foo.security.AppPerm1.”
With evolving e-business and discrete sets of permissions getting introduced by many application providers, the number of permissions that need to be handled grows exponentially. This also creates a tight coupling between the application provider and the security provider. This results in the security policy being placed in the application code, making code portability an issue. This tight coupling needs to be avoided to provide seamless support to varied applications.